Multi-key cryptographically generated address

ABSTRACT

A method for generating a network address, called a multi-key cryptographically generated address (MCGA), enables the network address to be claimed and defended by multiple network devices. The network address can be generated by (a) obtaining a cryptographically generated identifier using public keys corresponding to the network devices, and (b) applying an address generation function to the cryptographically generated identifier. The address generation function may be a one-way coding function or cryptographic hash of the public keys from all hosts that will advertise or claim the right to use the address. A message that claims authority over the MCGA may include an encrypted digest of the message which is encrypted using the private key of the sender. Authentication of the sender may be achieved by obtaining a test digest from the message using the digest function, decrypting the encrypted digest, and comparing the decrypted digest to the test digest. The signature is generated with only the private key of the host sending the message, but requires the public keys of all the network devices claiming authority to verify.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is related to and claims priority to U.S.provisional patent application, Ser. No. 60/677,712, filed on May 3,2005. The present application is also related to a co-pending patentapplication (“Co-pending Application”) entitled “Secure Address Proxyingusing Multi-key Cryptographically Generated Address,” filed on the sameday as the present application by the current inventors of the presentapplication and assigned to the current Assignee of the sameapplication. The Copending Application is hereby incorporated byreference herein in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to generating a network addresses for anode in a computer network. In particular, the present invention relatesto generating a network address for a node, the network address is to besecurely claimed and defended by the node and one or more other nodes inthe computer network.

2. Discussion of the Related Art

In a computer network, it is important to ensure that each networkaddress uniquely identifies a single network node.

U.S. Patent Application Publication 2002/0133607, entitled “AddressMechanisms in Internet Protocol” (the “Nikander Application”) disclosesusing a one-way coding function to generate an Internet Protocol (IP)address from one or more components specific to a host which claims theIP address. In the Nikander Application, a recipient of a message fromthe host reconstructs and checks the IP address using the components.The claiming host uses an authentication protocol or a public keycryptographic protocol to establish data integrity on the message, thetie between the components and the address.

U.S. Patent Application Publication 2002/0152384, entitled “Methods andSystems for Unilateral Authentication of Messages” (the “SchelestApplication”) discloses deriving an IP Version 6 (IPv6) address hashingthe claiming host's public key. In the Schelest Application, a recipientof a message from the claiming host checks the hash of the IPv6 address,and checks a cryptographic signature in the message to verify its dataintegrity. If both the IPv6 address and the enclosed signature areverified, the recipient accepts the host's claim of ownership over theIPv6 address. “Crypto-Based Identifiers (CBIDs): Concepts andApplications” (the “Montenegro Paper”) by Gabriel Montenegro and ClaudeCastellucia, ACM Transactions on Information and System Security,Feburary, 2004, reviews the area of cryptographically generatedidentifiers and their use in establishing authorization to claim theright to use an address by a single host.

U.S. Patent Application Publication 2003/00849293, entitled “AddressingMechanisms in Mobile IP” (the “Arkko Application”) discloses an ownernode delegating the responsibility for its IP address to a second nodewhen the address is generated. In the Arkko Application, the IP addressmay be cryptographically generated using the methods disclosed in theNikander or the Schelest Applications. Under the method of the ArkkoApplication, the owner node obtains a public key of a public/private keypair from the second node, and creates an authorization certificate bysigning the obtained public key using the owner node's own private key.The authorization certificate is then provided to the second node, whichmay then distribute it in any message relating to the owner node's IPaddress. The second node signs this message, including the authorizationcertificate, with its private key. A recipient node uses the secondnode's public key to verify the message and the owner node's public keyto verify the authorization certificate. The cryptographic hash of theaddress verifies the owner node's right to the address and the verifiedsecond node's public key in the authorization certificate establishesthe second node's right to send messages on behalf of the owner node.

IETF Request for Comment (RFC) 3972, by Aura, March 2005, disclosesgenerating, cryptographically, an IPv6 address and securing the claim ofauthorization for the IPv6 address in the Neighbor Discovery Protocol(RFC 2461 and RFC 2462). The IPv6 address is generated using both thecryptographic hash of the public key of the owner node and additionalinformation. 64 bits of cryptographic hash serves as the interfaceidentifier of the IPv6 address.

As can be seen from the above, the Nikander and Schelest Applications,the Montenegro Paper, and RFC 3927 relate only to cases in whichauthorization to use the network address is claimed by a single host.Often, however, it may be necessary to authorize one or most hosts touse an address. Some examples can be found in mobile IPv6 networks andDHCP applications

In a mobile IPv6 network, a mobile node may be reached using a homeaddress on a home network to which the mobile node is assigned. The homeaddress does not change regardless of where the mobile node is on theInternet. When the mobile node is in a remote subnet outside of its homesubnet, a “home agent” (e.g., a router on the mobile node's home subnet)forwards messages addressed to the home address of the mobile node to a“care of” address, which is a local address in the remote subnet. Toprevent the home address from being claimed by another when the mobilenode is away from the home network, the home agent must proxy, ordefend, the mobile node's home address. However, if the mobile nodegenerates the home address using a cryptographic identifier tied to itspublic key, only it can securely defend the home address. The proxydefense by the home agent must be done without security.

Under the IPv6 Neighbor Discovery Protocol, even when a host's addressis obtained from a Dynamic Host Configuration Protocol (DHCP) server,the host is still required to claim and defend that address on thenetwork. However, such claim and defense cannot be done securely usingcryptographically generated addresses because the address is generatedby the DHCP server without the host's public key. Nor can the host signwith its private key a message relating to the address, as the host didnot generate the address.

While the Arkko Application discloses an owner node delegatingadvertising and defense of its address to another party, the solution inthe Arkko Application is cumbersome. In the Arkko Application, inaddition to using both the owner node's and the delegated node's publickeys, an attribute certificate is also required. After generating theaddress, the attribute certificate is sent by the owner node to thedelegated node. As described in the Arkko Application, the solution inthe Arkko Application identifies whether the claimant is the owner nodeor the delegated node. This information can be used by an attacker toinfer the location or other information about the owner host.

SUMMARY

The present invention provides a method for generating a network addressthat can be claimed and defended by multiple network devices. Such anetwork address is called a multi-key cryptographically generatedaddress (MCGA). According to one embodiment of the invention, thenetwork address can be generated by (a) obtaining a cryptographicallygenerated identifier using public keys corresponding to the networkdevices, and (b) applying an address generation function to thecryptographically generated identifier. The address generation functionmay be a one-way coding function or a cryptographic hash of the publickeys from all hosts that will advertise or claim the right to use theaddress.

In one embodiment, a message is sent by one of the network devices toclaim the authority to use the network address. The message includes adigest of the message signed by the sending network devices using itsprivate key. A multi-key signature, such as a ring signature, may alsobe used to cryptographically sign a message that claim the right to usethe address or otherwise request operations. Alternatively, the messagecan be signed using a private key corresponding to the public keys usedto generate the network address, and the message can indicate whichpublic key may be used to validate the signature. Such a message may bea change in routing to be performed on the network address, for example.The MCGA may be used as source and destination addresses of a packet, orotherwise included in the message.

To verify the sending network device's claim of authority on the networkaddress, the recipient of the message verifies the network address. Inone embodiment, to verify the network address, the recipient extractsfrom the network address a copy of the cryptographically generatedidentifier included in the message. Based on its knowledge of how thecryptographically generated identifier is obtained, the recipient alsogenerates a test cryptographically generated identifier from the publickeys. The recipient compares the test cryptographically generatedidentifier with the extracted copy of the cryptographically generatedidentifier.

In one embodiment, the cryptographically generated identifier is createdusing public keys corresponding to the multiple network devices. Thetest cryptographically generated identifier is generated using all thesepublic keys.

In one embodiment, the message further includes an encrypted digest ofthe message which is encrypted using the private key corresponding toone of the network devices. Authentication of the sender of the messagemay be achieved by obtaining a test digest from the message using thedigest function, decrypting the encrypted digest, and comparing thedecrypted digest to the test digest. The signature is generated withonly the private key of the host sending the message, but requires thepublic keys of all the network devices claiming authority to verify.Unlike the prior art, when both an owner and a delegated host may claimand defend a network address, the present invention requires merely thepublic keys of the host and the delegated host prior to generating theaddress. No secure communication is required between the owner and thedelegated host to notify the delegated host of the network address. Theowner and the delegated host can independently sign messages claimingauthorization of right to use the address using their respective privatekeys. Co-ordination as to which node has the responsibility at aparticular time to defend the network address may be established usingsome other protocol, such as the Mobile IP protocol or DHCP. Accordingto one embodiment of the present invention, when used with a multi-keysignature algorithm that preserves anonymity, the network address wouldnot identify which is the owner and which is the delegated host.

In one embodiment, a network node receiving a message claimingauthorization for the address first checks the address by checkingwhether it was generated using a one-way coding function or acryptographic hash of the public keys. The network node then checks thesignature using the public keys. If both checks succeed, the receivingnode knows that the sender is one of the nodes authorized to use theaddress, and therefore that it is safe to perform the requestedoperation.

Thus, the invention allows more than one network device to securelyclaim authorization of right to use an address. Verification of themulti-key cryptographically generated address and the signature on themessage by a receiving network device establishes the authenticity ofthe claim of authorization.

The present invention is better understood upon consideration of thepresent invention and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is flow chart 100 illustrating device d_(i) calculating amulti-key cryptographically generated address (MCGA) from public keyspk₁-pk_(n) of devices d₁, . . . , d_(n), cryptographic identifiergeneration parameters, and address space parameters.

FIG. 2 is flow chart 200 illustrating device d_(i) signing message mclaiming authorization to use a MCGA.

FIG. 3 is flow chart 300 illustrating, in a receiving device, verifyingmessage m, which includes a claim of authorization to use a MCGA.

FIG. 4 shows network devices d₁, . . . , d_(n) communicating overnetwork 40; some of network devices d₁, . . . , d_(n) may claim theright to use an address in network 40, in accordance with the presentinvention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The prevent invention allows a network device to generate a networkaddress for which the authorization for the right to use may be claimedby multiple devices. The invention is applicable to a computer networkshown, for example, in FIG. 4, where network devices d₁, . . . , d_(n)communicates over network 40. Some of network devices d₁, . . . , d_(n)may claim the right to use an address in network 40, in accordance withthe present invention. FIG. 1 is flow chart 100 illustrating deviced_(i) calculating a multi-key cryptographically generated address (MCGA)from public keys pk₁-pk_(n) of devices d₁, . . . , d_(n), cryptographicidentifier generation parameters, and address space parameters. Devicesd₁, . . . , d_(n) claim authority to use the MCGA.

As shown in step 101 of flow chart 100, the network-connected device(say, d₁) obtains public keys pk₂, . . . , pk_(n), of the other devicesd₂, . . . , d_(n), respectively, claiming authorization for the right touse the network address to be generated. At step 102, using its own andthe obtained public keys, device d₁ creates a cryptographicallygenerated identifier cid using a one-way coding function CODE-F (e.g., acryptographic hash function):cid=CODE−F(pk ₁ , . . . , pk _(n) ,x)where x is one or more other parameters which provide additional entropyor uniqueness, or which indicate particular conditions involving theaddress or its generation.

At step 103, using the cryptographically generated identifier cid,device d₁'s network address net-addr is then generated using a suitableaddress generation function addr-f for the address space of the network(e.g., IPv6, IPv4, IEEE 802 MAC addresses):net−addr=addr−f(cid, y)

where y is one or more other parameters specific to the network addressspace or generation technique needed to turn cid into a valid networkaddress.

For example, in an IPv6 network, an appropriate network addressIPv6-addr may be formed using the HMAC-SHA1 cryptographic hash function:cid=HMAC-SHA1((pk ₁ |pk ₂ | . . . |pk _(n))|(s ₁ |s ₂ | . . . s _(n)))IPv6−addr=IPv6_prefix|Btruc64(cid)

where | is the bit-wise concatenation function, IPv6_prefix is a 64-bitsubnet prefix, Btruc64 is a function that extracts the lower 64-bits ofits argument, and s_(k) is a private key-derived digital signature on astring of zero bits.

FIG. 2 is flow chart 200 illustrating device d_(i) signing message mclaiming authorization to use a MCGA. After generation of the MCGA,device d_(i) may send a network protocol message msg. The recipient ofmessage msg may require device d_(i) to prove its authorization to usethe address. To demonstrate its authorization, device d_(i) generates adigital signature sig on the message using a multi-key or single keydigital signature calculation function SIGN (e.g., a ring signaturefunction, or a single key signature function). First, at step 201, adigital digest of message msg is obtained:digest=DIGEST−F(msg)

At step 202, the generated digest is signed:sig=SIGN(pvk _(i), digest)

where pvk_(i) is the private key of a pk_(i)/pvk_(i) key-pair (e.g., astandard RSA public key/private key pair).

At step 203, the signed digest, the public keys pk₁, . . . , pk_(n) ofall claimants of the network address, and the cryptographic identifiergeneration parameters are included in message msg.

In one embodiment, a ring signature rs for message m may be used. Assumethat DIGEST-F, described above, is a “collision-resistant” hash functionthat outputs a d-bit string. (“Collision-resistant” is a term used inthe cryptographic literature meaning that it is computationally “hard”to find strings x and y such that x is not equal toy andDIGEST−F(x)=DIGEST−F(y).) Let E be an encryption scheme that uses d-bitkeys and has b-bit input and output. (We impose an additional conditionon b below.) Let t be a parameter—e.g., t may equal 80. Let · denote theXOR function.

The public keys in the ring signature are the same as public keys inRSA. Specifically pk(i)=(N(i), e(i)), where N(i) is a large (e.g.,1024-bit) composite integer that is the product of two large primenumbers p(i) and q(i) and where e(i) is an integer that is relativelyprime to (p(i)−1)(q(i)−1). Let b be an integer such that 2^(b)>2^(t)N(i)for all i.

The ring signature is generated as follows. Let pk(i) be the public keyof the “real” signer. The signer:

-   -   1. Sets symmetric encryption key k to be DIGEST-F(m), where m is        the message to be signed;    -   2. Picks a random b-bit string v;    -   3. For j from 1 to n (except j is not equal to i):        -   a. Picks random b-bit string x_(j);        -   b. Computes (q_(j), r_(j)) such that x_(j)=q_(j)N(j)+r_(j)            for r_(j) in the interval [0, N(j)];        -   c. Computes y_(j)′=x_(j) ^(e(j)) (mod N(j)) for y_(j)′ in            the interval [0, N(j)];        -   d. Sets y_(j)=q_(j)(j)+y_(j)′;        -   e. Goes to Step 3 a if y_(j) is greater than or equal to            2^(b);    -   4. Computes y_(i) such that E_(k)(y_(n)·E_(k)(y_(n−1)·E_(k)(. .        . ·E_(k)(y₁·v) . . . )))=v;    -   5. Computes (q_(i), r_(i)) such that y_(i)=q_(i)N(i)+r_(i) for        r_(i) in the interval [0, N(i)];    -   6. Computes x_(i)′=y_(i) ^(1/e(i)) (mod N(i)) for x_(i)′ in the        interval [0, N(i)];    -   7. Sets x_(i)=q_(i)N(i)+x_(i)′;    -   8. Goes to Step 3 if x_(i) is greater than or equal to 2^(b);    -   9. Outputs the ring signature (x₁, . . . , x_(n), v).

Above, if t is large enough, there will be only a negligibly smallprobability that the signature generation algorithm will abort in Step 3e or Step 8 because y_(j) or x_(i) spills out of the permitted range of[0, 2^(b)). Regarding Step 4 of signature generation above, notice that:y _(i) =E _(k) ⁻¹(y _(n) ·E _(k) ⁻¹( . . . y_(i+1) ·E _(k) ⁻¹(v)))·E_(k)(y _(i−1) ·E _(k)( . . . ·E _(k)(y ₁ ·v))).

In general, device d_(i) inserts signature sig, the address generationparameters x (if required), the public keys pk₁-pk_(n), and the addressnet-addr into a message msg claiming authorization for use of theaddress.

FIG. 3 is flow chart 300 illustrating, in a receiving device, verifyingmessage m, which includes a claim of authorization to use a MCGA. Atstep 301, the receiving device of message msg checks authorization ofright to use address net-addr by first repeating the address calculationto obtain a test cryptographically generated identifier. At the sametime, the cryptographically generated identifier cid is taken from theaddress on message msg (step 302). Cryptographically generatedidentifier cid is then compared to the test cryptographically generatedidentifier to determine whether the claimed address can be generatedusing the public keys pk₁-pk_(n) and the address generation parameters x(step 303). If the determination fails (i.e., the cryptographicallygenerated identifiers do not match), message msg is rejected.

Then, at steps 305-308, the receiving device checks signature sig usingpublic keys pk₁-pk_(n) using a multi-key verification function VERIFY:v=VERIFY (sig, pk ₁ , pk ₂ , . . . , pk _(n), msg)

Function VERIFY extracts initially (step 304) a test digest of messagemsg using the public keys and the message content. The signed digest inmessage msg is decrypted by applying the public keys. The decrypteddigest is then compared with the test digest (step 305). If thesignature cannot be verified, function VERIFY returns v as 1 (step 306).Otherwise, VERIFY returns v as 0 (step 307).

In the ring signature example above, the verification of ring signaturers(x₁, . . . , x_(n), v) in message m in the example discussed above maybe calculated as follows:

-   -   1. Sets symmetric encryption key k to be DIGEST-F(m), where m is        the message to be signed;    -   2. For j from 1 to n:        -   a. Computes (q_(j), r_(j)) such that x_(j)=q_(j)N(j)+r_(j)            for for r_(j) in the interval [0, N(j)];        -   b. Computes y_(j)′=x_(j) ^(e(j)) (mod N(j)) for y_(j)′ in            the interval [0, N(j)];        -   c. Sets y_(j)=q_(j)N(j)+y_(j)′;    -   3. Confirms that v=E_(k)(y_(n)·E_(k)(y_(n−1)·E_(k)( . . .        ·E_(k)(y₁·v) . . . )))=v.

The above detailed description is provided to illustrate specificembodiments of the present invention and is not intended to be limiting.Numerous modifications and variations within the scope of the presentinvention are possible. The present invention is set forth in theaccompanying drawings.

1. A method for generating a network address relating to multiple network devices, comprising: obtaining a cryptographically generated identifier using public keys corresponding to the network devices; and applying an address generation function to the cryptographically generated identifier to create the network address.
 2. A method as in claim 1, wherein the address generation function is selected from a one-way coding function and a cryptographic hash function using public keys.
 3. A method as in claim 1, further comprising: creating a digest of a message; and signing the digest of the message using a private key corresponding to one of the network devices.
 4. A method as in claim 3, the signing creates a public key signature.
 5. A method for verifying a claim of authority to use a network address, comprising: receiving a message bearing a network address generated by applying an address generation function on a cryptographically generated identifier, the message included therein a copy of the cryptographically generated identifier; extracting from the message the copy of the cryptographically generated identifier; obtaining a test cryptographically generated identifier; and comparing the test cryptographically generated identifier to the extracted copy of the cryptographically generated identifier.
 6. A method as in claim 5, wherein the cryptographically generated identifier is created using public keys corresponding to the network devices.
 7. A method as in claim 5, wherein the message further comprises an encrypted digest of the message.
 8. A method as in claim 7, wherein the digest of the message is encrypted using the private key corresponding to one of the network devices.
 9. A method as in claim 7, further comprises: obtaining a test digest from the message; decrypting the encrypted digest; and comparing the decrypted digest to the test digest.
 10. A system comprising: a first network device associated with a first public key; and a second network device associated with a second public key, wherein the second network device obtains a cryptographically generated identifier using the first and second public keys, the cryptographically generated identifier being used in connection with an address generation function to create a network address.
 11. A system as in claim 10, wherein the address generation function is selected from a one-way coding function and a cryptographic hash function using public keys.
 12. A system as in claim 10, wherein the second network device creates a digest of a message; and signs the digest of the message using a private key corresponding to the second public key.
 13. A system as in claim 12, wherein the signing creates a public key signature.
 14. A system as in claim 10, wherein the second network device includes the network address and the cryptographically generated identifier in a message to the first network device, and wherein, the first network device, upon receiving the message, (1) extracts from the message the copy of the cryptographically generated identifier; (2) obtaining a test cryptographically generated identifier using the public keys and the address generation function; and (3) compares the test cryptographically generated identified to the extracted copy of the cryptographically generated identifier.
 15. A system as in claim 14, wherein the cryptographically generated identifier is created using public keys corresponding to the network devices.
 16. A system as in claim 15, wherein the message further comprises an encrypted digest of the message.
 17. A system as in claim 16, wherein the digest of the message is encrypted using the private key corresponding to one of the network devices.
 18. A system as in claim 16, wherein the first network device (a) obtains a test digest from the message, decrypts the encrypted digest; and compares the decrypted digest to the test digest.
 19. A computer-readable medium, including computer-executable instructions for generating a network address relating to multiple network devices, wherein the instructions performing: obtaining a cryptographically generated identifier using public keys corresponding to the network devices; and applying an address generation function to the cryptographically generated identifier to create the network address.
 20. A computer-readable medium as in claim 19, wherein the address generation function is selected from a one-way coding function and a cryptograhic hash function using public keys.
 21. A computer-readable medium as in claim 19, further comprising computer-executable instructions for: creating a digest of a message; and signing the digest of the message using a private key corresponding to one of the network devices.
 22. A computer-readable medium as in claim 21, wherein the signing creates a multi-key signature.
 23. A computer readable medium, including computer-executable instructions for verifying a claim of authority to use a network address, comprising: receiving a message bearing a network address generated by applying an address generation function on a cryptographically generated identifier, the message included therein a copy of the cryptographically generated identifier; extracting from the message the copy of the cryptographically generated identifier; obtaining a test cryptographically generated identifier; and comparing the test cryptographically generated identified to the extracted copy of the cryptographically generated identifier.
 24. A computer-readable medium as in claim 24, wherein the cryptographically generated identifier is created using public keys corresponding to the network devices.
 25. A computer-readable medium as in claim 23, wherein the message further comprises an encrypted digest of the message.
 26. A computer-readable medium as in claim 25, wherein the digest of the message is encrypted using the private key corresponding to one of the network devices.
 27. A computer-readable medium as in claim 25, further comprising computer-executable instructions for: obtaining a test digest from the message; decrypting the encrypted digest; and comparing the decrypted digest to the test digest. 